A distributed platform involves a set of interoperating servers. The collective footprint of the set of servers provides a computational resource that is scalable, fault tolerant, and able to withstand heavy computational workloads. When such a distributed platform is a content delivery network (CDN), the set of servers provides a shared computing resource that is leveraged for the wide scale and optimized dissemination of content for numerous CDN customers. Specifically, the set of servers interoperates to cache the CDN customer content at multiple geographic locations and to serve the cached in an optimized fashion in order to reduce latency while providing security, failover via redundancy, and other benefits.
FIG. 1 depicts an exemplary Content Delivery Network (CDN) architecture providing optimized content delivery on behalf of various content provider customers of the CDN. As shown, the CDN includes several different caching Points-of-Presence (PoPs) 110, traffic management servers 120, and an administrative server 130. The figure also illustrates the interactions that CDN customers, including content providers, have with the CDN and interactions that content consumers or end users have with the CDN.
Each PoP 110 may be representative of a server farm for a geographically proximate set of physically separate servers or a set of virtual servers that execute over partitioned sets of resources of one or more physically separate servers. The PoPs are distributed across different network edges of the Internet. The servers in each respective PoP cache and serve content on behalf of different content providers to end users, thus facilitating the “last mile” delivery of content. Hence, the PoP servers are referred to as “edge servers”, “storage servers”, or “caching servers”. A caching server may cache the same content as other caching servers in the same PoP or may be configured to cache different content than the other caching servers in the same PoP.
The traffic management servers 120 route end users, and more specifically, end user issued requests for content to one or more caching servers that can optimally deliver the requested content back to the end users. In many cases, the optimal caching server is a server caching the requested content in a PoP that is geographically closest to the end user that issued the content request. Different CDN implementations utilize different traffic management schemes to achieve such routing to the optimal caching servers. For example, the traffic management scheme can be conducted according to Anycast routing. However, other traffic management schemes, such as Domain Name System (DNS) routing, can alternatively be used and the traffic management servers 120 can include different combinations of DNS servers, load balancers, and routers performing Anycast, DNS, or Border Gateway Protocol (BGP) routing as some examples.
The administrative server 130 may include a central server of the CDN or a distributed set of interoperating servers that perform the configuration control and reporting functionality of the CDN. Content providers register with the administrative server 130 in order to access services and functionality of the CDN. Accordingly, content providers are also referred to as customers of the CDN. Once registered, content providers can interface with the administrative server 130 to specify a configuration, upload content, and perform operations, such as purge operations, to manage, update, and customize their CDN configuration and content. The administrative server 130 also aggregates statistics data from each server of the set of caching servers and processes the statistics to produce usage and performance reports for the customers.
In any distributed platform, such as the CDN depicted in FIG. 1, seemingly trivial operations become significantly more complex and challenging when those operations have to be coordinated and executed across the set of servers. Content purging is one such operation. Content purging involves the removal of content or the removal of the one or more files that represent the content from the set of servers.
Content purging in a distributed platform is typically conducted in one of two ways. In a first scenario, the distributed platform monitors which servers host which content in order to target the purge operation to the servers that actually host the content that is to be purged. This monitoring and server targeting introduces overhead, complexity, and lag which is only exacerbated when supporting wildcard purging, purges involving query string parameters, compressed files, or “hot” files (i.e., files that are replicated to other servers during a temporary period of high demand). This scenario also can become untenable when the distributed platform is a CDN. CDN caching servers frequently change the content they cache. The messaging needed to convey the cache changes would unnecessarily occupy caching server resources, thereby degrading their overall responsiveness and content delivery performance.
In an alternate scenario, the distributed platform sends each purge operation to all servers of the distributed platform for execution irrespective of whether or not those servers actually host the content designated for purging. This scenario is more typical for a CDN, but also resource and time intensive. To confirm execution of a purge operation, the distributed platform awaits confirmation from each of the servers that the purge has been completed. To complete the purge, each server that hosts the content performs a resource intensive file system traversal and write operation to locate and expunge the targeted files or directories. Compared to processor computations, file system operations, such as the write operation, are several magnitudes slower. The file system operations can also be blocking. In other words, file system reads and writes cannot be performed concurrently due to resource contention. This is especially problematic for the CDN caching servers.
The CDN caching servers continually perform read operations in order to serve content from cache in response to requests from content consumers. However, the CDN caching servers are also continually performing write operations by changing or maintaining the contents of their cache and removing content in response to CDN customer purge operations. In such cases, either the write operation or the read operation may block the file system, thus preventing the other operation from completing. When a purge takes several seconds to complete due to large file sizes or a large number of files being purged, the caching server is unable to respond to the incoming content requests, thereby creating a bottleneck and degrading the overall content delivery performance of the distributed platform. To avoid this bottleneck potential, some servers delay the purge until they experience some momentary downtime or period of inactivity in which they can safely perform the purge without impacting primary operation of the server. This however further prolongs the amount of time needed to complete a purge. Such a significant delay is unacceptable for on-demand or real-time services.
For these and other reasons, most distributed platforms do not and cannot offer instantaneous or on-demand removal of files. The customers of these distributed platforms often wait several minutes before their issued purge operations are executed. Accordingly, there is a need for a solution that improves purging in a distributed platform. More specifically, there is a need for instantaneous non-blocking purging systems and methodologies for a distributed platform.